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THE  "FACTORY"  APPROACH  TO  LARGE-SCALE  SOFTWARE  DEVELOPMENT: 
IMPLICATIONS   FOR  STRATEGY.   TECHNOLOGY.   AND  STRUCTURE 


The  impact  of  technology  on  organizational   structure   is   a   concern    linking 
the  fields  of  business   history,    strategy   research,    organizational   theory, 
production   and  technology  management,    and  comparative   international   studies. 
These  diverse   literatures   have  all   treated  a   basic  managerial   dilemma    resulting 
from  two  opposing   demands:      (1)    the  desire  of  consumers    (and   perhaps 
marketing   strategists)    for  variety   in   product  offerings;    and    (2)    the  desire  of 
managers    responsible  for  engineering   and   production   for  standardization   of 
tools,    components,    and   procedures   as   a  way  to   reduce  complexity  and  costs    in 
product  development  and  manufacturing,    as   well   as   in   testing   and   customer 
service. 

Laboratory  or   "job-shop"   types  of  organizational   structures    have 
traditionally  been   seen   as  the  most  flexible  way  to  design   and  construct  a 
variety  of  products,    but  at  high   expense,    due  to  the  absence  of  economies  of 
scale  and   scope.      It   has   also  been   assumed   in   various   studies   that,    as   a 
technology   "matures"  over  time  and  firms   better  understand  product-market 
characteristics,    they  can   move  toward   more  efficient  means  of  production. 
Mass-production   engineering   and   manufacturing  organizations   are   usually   seen   as 
occupying  the  upper  end  of  the   resulting   spectrum   --   maximum  efficiency   in 
terms  of  costs   per  unit,    but   little  flexibility   in   terms   of   introducing   new 
products  or  processes   quickly. 

The  basic  argument  of  this   paper  and   a   series  of  case  studies   in 
preparation    is   that  organizational  type  and  process   choices    --   such   as  job   shops 
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versus  more  rationalized  factory  environments,  standardizing  inputs  and 
procedures  --  may  not  be  as  influenced  as  the  literature  suggests  by  the 
inherent  characteristics  of  a  technology  or  specific  product  types,  or  the 
assumed  level  of  industry  "maturity."  Managers  even  of  relatively  new  and 
complex  technologies  might  still  formulate  strategies  to  improve  efficiency  in 
product  development  and  processing  operations;  and  implementing  these 
strategies  can  result  in  very  different  types  of  organizations,  even  for  similar 
products   in   a    relatively   new  industry. 

This  paper  treats  a  specific  segment  of  a  new  technology  --  large-scale 
software  development  for  mainframes  and  minicomputers.  It  asks  a  specific 
question:  If  one  tries  to  measure  structure  by  some  simple  indicators  of  inputs 
and  process  standardization  and  control,  do  producers  of  similar  software 
products  follow  different  process  strategies  --  for  example,  corresponding  to  job 
shops  on  one  end  of  a  hypothetical  spectrum  and  more  factory-like 
organizations  on  the  other?  The  survey  evidence  presented  here  of  38  software 
facilities  or  product  areas   in  the  U.S.    and  Japan   is  that  they  do. 

The  conclusion  follows  that,  if  some  firms  are  more  intent  than  others  on 
disciplining  a  technology  and  using  organizational  structure  as  a  way  to  compete 
more  effectively,  then  competitive  strategy  and  effective  implementation  are  at 
least  as  important  if  not  more  important  than  the  nature  of  a  particular 
technology  in  shaping  the  organization.  This  is  consistent  with  Chandler's  basic 
dictum  that  structure  should  follow  strategy  (Chandler  1962);  another  question  is 
to  what  extent  technology  might  be  a  constraining  factor  on  managerial 
effectiveness  or  structure.  It  was  hoped  when  designing  this  study  that  a  set 
of  criteria  would  make  it  possible  to  identify  which  firms  seem  more  committed 
to  disciplining  software  technology;  and  that  studying  these  firms  in  detail 
would    then    provide    some    general    insights     into    effective    strategies    and 


organizational    structures   for  managing   product   and   process   development   for  a 
relatively   new  and  complex   technology. 


THE  PROBLEM  FRAMED   IN   DIFFERENT   LITERATURES 

Business  historians  have  long  maintained  that  production  organizations 
evolved  over  time  and  with  accumulations  of  product  and  process  knowledge, 
moving  from  craft-like  job  shops  to  mass-production  factories.  Most  prominent 
is  Chandler,  who  has  described  the  evolution  of  factories  during  the  18th  and 
19th  centuries  in  Britain,  Europe  and  the  United  States,  initially  in  the  textile 
industry  and  then  gun-making.  This  historical  view  has  interpreted  this 
movement  as  driven  by  managers  attempting  to  raise  worker  productivity  and 
lower  unit  costs  by  standardizing  and  then  integrating  production  processes  in  a 
large,  centralized  facility;  developing  interchangeable  components;  closely 
coordinating  the  flow  of  each  process;  dividing  and  specializing  labor; 
mechanizing  or  automating  tasks;  and  imposing  rigid  accounting  controls 
(Chandler   1977;    Skinner   1985). 

In  the  area  of  industrial  organization  theory,  a  school  of  thought  rather 
complementary  to  Chandler  has  tended  to  see  the  characteristics  of  a  particular 
technology,  including  inputs,  processing,  and  outputs,  as  determining  in  large 
part  how  an  organization  evolves.  Most  important  was  Woodward  (1965,  1970), 
who  identified  three  basic  types  of  production  organizations,  ranging  from  unit 
job  shops  and  small-batch  production,  to  large-batch  and  mass  production,  to 
continuous  processing  operations  as  in  chemical  manufacturing.  The  assumption 
here  was  that  over  time  operations  tended  to  become  larger  in  scale  and  more 
complex,  making  it  necessary  for  organizations  to  become  larger  and  more 
complex,   too,    as  they  evolved  from  unit  or  batch  operations  to  mass  producers 


or  continuous-production  operations. 

Somewhat  in  contrast,  the  contingency  theory  school,  led  by  Lawrence  and 
Lorsch  (1967)  as  well  as  Galbraith  (1973,  1977),  has  argued  there  is  no  one  best 
way  to  design  the  structure  of  an  organization  to  manage  a  particular 
technology.  What  structure  is  most  effective  or  appropriate  depends  on  "what 
environmental  demands  or  conditions  confront  the  organization"  (Scott,  1981: 
208).  A  recent  case  study  of  medical-imaging  scanner  introduction  similarly 
concluded  that  identical  technologies  can  result  in  different  structural  outcomes, 
depending  "on  the  specific  historical  process  in  which  they  are  embedded" 
(Barley   1986:    107). 

Production  and  operations  management  specialists  such  as  Abernathy  and 
Utterback  (1975),  Hayes  and  Wheelright  (1979  and  1984),  and  Schmenner  (1984) 
have  also  focused  on  the  range  of  product  and  process  options  open  to  a  firm 
as  product  technologies  mature  in  a  sort  of  life  cycle.  As  with  Chandler  and 
Woodward,  the  underlying  notion  is  that  firms  tend  to  take  advantage  of 
accumulated  experience  and  innovate  to  rationalize  their  process  technology. 
The  tradeoff  in  rigidity  as  a  firm  moved  toward  continuous  production  used  to 
be  extensive,  because  designs  and  processes  became  difficult  and  expensive  to 
change.  Indeed,  the  experience  of  Ford  and  its  Model  T  production  facilities  in 
the  1920s  demonstrates  how  a  company  can  drive  itself  into  near  bankruptcy  by 
pushing  such  strategic  commitments  too  far  --  for  example,  assuming  product 
technology  or  consumer  tastes  were  more  stable  than  they  were,  and  making 
factory  systems  so  rigid  they  took  long  periods  of  time  to  change  to  new- 
product  or  process  technologies  (Abernathy  and  Wayne  1974).  Abernathy  and 
Wayne  cited  the  Ford  example  to  encourage  managers  to  exercise  caution  before 
assuming  a  process  technology  was  mature  and  then  instituting  the  type  of 
technological    systems    and    procedural    standardization    commonly    needed    to 


operate  a   highly   rationalized  mode  of  production. 

Strategy  theory  has  pointed  out  that  creation  of  an  organization  capable 
of  combining  product  differentiation  and  process  efficiency  may  provide  a  rare 
but  powerful  combination  of  competitive  skills  (Porter  1980,  1985).  Recent 
developments  in  design  and  production  techniques  have  in  fact  reduced  the  need 
for  traditionally  accepted  tradeoffs  between  process  flexibility  and  efficiency 
and  thus  created  capabilities  that  help  firms  rationalize  development  processes 
without  simply  producing  standardized  goods  or  locking  an  organization  into  a 
single  mode  of  production. 

For  example,  during  the  1950s  and  1960s,  Japanese  auto  firms  pioneered 
"small-lot  production"  techniques,  standardizing  methods  and  inputs  but  not 
producing  large  lots  of  standardized  final  products  due  to  machinery  and 
workers  capable  of  quickly  changing  to  perform  different  operations  or  jobs 
(Schonberger  1982;  Monden  1983;  Cusumano  1985).  Producers  of  machine  tools, 
textile  equipment,  and  various  metal  components  have  also  managed  to  combine 
"small-lot"  or  job-shop  flexibility  in  end-product  variety  with  the  efficiency, 
quality,  and  management  control  of  large  factories  (Jaikumar  1984  and  1986; 
Piore  and  Sabel  1984;  Sabel  1987;  Palframan  1987).  Group  technology  concepts 
(putting  together  similar  parts,  problems,  or  tasks)  facilitate  scheduling  of  parts 
production  or  arranging  factory  layouts  as  well  as  rationalizing  product  design 
and  engineering  (Hyer  and  Wemmerloc  1984).  Producers  of  semiconductors,  like 
their  counterparts  in  older  industries  like  automobiles,  routinely  use 
standardized  components  and  add  end-process  customization  (Harvard  Business 
School  1986).  Computer-aided  design  integrated  with  flexible  manufacturing 
systems  (FMS)  transfer  digitalized  designs  automatically  to  manufacturing  tools, 
allowing  firms  to  automate  this  combining  of  modularized  designs  with  new 
designs    (Skinner   1985;   Jaikumar   1986;    Meredith    1987). 


Comparative  international  studies  have  added  a  further  observation,  noting 
the  tendency  of  firms  in  certain  countries  to  develop  similar  sets  of  strategies 
and  structures.  As  noted,  the  small  size  of  the  domestic  Japanese  automobile 
market  apparently  persuaded  managers  to  develop  flexible  manufacturing  systems 
during  the  1950s  and  1960s  (Cusumano  1985).  There  appears  to  have  been  a 
similar  trend  in  the  Japanese  machine  tool  industry  (Jaikumar  1986).  Countries 
such  as  Italy  also  seem  to  have  produced  a  large  number  of  firms,  many  of 
them  textile  machinery  producers,  emphasizing  this  combination  of  efficiency 
and  specialization  (Piore  and  Sabel  1984).  A  survey  of  55  U.S.  and  51  Japanese 
manufacturing  plants  also  found  that  the  Japanese  tended  to  establish  similar 
types  of  manufacturing  organizations,  oriented  toward  more  efficient, 
continuous-type  processing  operations   (Lincoln,   Hanada,   and  McBride  1986). 

Difficult  to  separate  are  the  effects  of  simply  being  from  a  certain  culture 
or  nation,  from  the  tendency  of  managers  in  that  country  to  respond  in  kind  to 
similar  environmental  conditions.  Nonetheless,  the  question  must  still  be 
answered  to  what  degree  managers  actually  have  and  exercise  options  to 
emphasize  similar  or  different  strategies  for  dealing  with  a  particular 
technology.  It  also  is  not  clear  to  what  extent  the  peculiar  characteristics  of  a 
technology  might  constrain  the  ability  of  managers  to  rationalize  product 
development  and  production  operations.  These  questions  can  be  examined  at 
least  in  part  by  seeing  if  firms  producing  similar  software  products  do  so  in 
different  manners,  with  strategies  and  processing  organizations  ranging  from  job 
shops  or  laboratories  to  more  factory-like  models. 


THE  CASE  OF  LARGE-SCALE  SOFTWARE  DEVELOPMENT 

Software  production   dates   back  to  the   1950s,    when   computers  were  first 


designed  that  could  store  in  internal  memory  sets  of  instructions  (programs) 
controlling  basic  operations  and  a  variety  of  applications.  As  it  has  become 
refined  over  time,  the  series  of  phases  followed  in  software  development  has 
come  to  resemble  that  for  "hard"  products,  consisting  of  planning,  detailed 
design,  construction  (coding),  testing,  and  servicing  (maintenance)  phases.  It 
typically  takes  years  and  hundreds  of  employees  to  develop  and  test  programs 
such  as  operating  systems  for  large  mainframe  computers  or  real-time  control 
systems  for  factories  or  electric  power  plants.  Furthermore,  the  clarity  of 
designs,  consistency  of  documentation,  and  lack  or  presence  of  defects  or 
inadequate  designs  requiring  extensive  future  modifications  could  impose 
enormous  costs  on  software  producers.  Development  costs  for  software 
programs  over  their  lifetimes  were  typically  about  10%  for  planning  and  design, 
less  than  10%  for  coding,  about  15%  for  testing,  and  as  much  as  70%  for 
maintenance   (Frank   1983). 

As  with  hard  manufacturing,  it  is  difficult  to  generalize  about  software 
because  there  are  numerous  types  of  products  for  a  wide  variety  of  computers 
and  applications.  These  fall  into  two  basic  categories:  "systems'  software, 
including  operating  systems,  database  management  systems,  telecommunications 
and  other  related  programs  designed  to  operate  the  basic  functions  of  the 
computer  or  computer  system;  and  "applications  '  programs,  which  operate  a  level 
above  and  implement  specific  functions  like  production  control,  payroll  analysis, 
or  word  processing.  Applications  include  "packaged"  software  --  products 
designed  by  producers  for  general  sale  --and  customized  software  --  programs 
tailored   to  meet  the   unique  needs  of  an    individual   customer. 

Firms,  or  at  least  facilities,  tend  to  specialize  in  particular  types  of 
software  products,  making  it  possible,  theoretically,  for  them  to  achieve 
economies  of  scale  or  scope  through   standardization  of  tools,   procedures,   and 


inputs.  In  other  industries,  the  rigidity  imposed  by  such  "rationalization," 
resulting  in  a  reduced  ability  to  adapt  to  changes  in  product  or  process 
technologies,  or  in  market  demands,  has  traditionally  been  seen  as  the  major 
tradeoff  a  firm  accepts  in  moving  toward  design  standardization  or  factory 
mass-production.  Software  development  may  seem  to  be  primarily  a  set  of 
design  and  engineering  activities  for  one-of-a-kind  products,  in  the  sense  that 
companies  make  packages,  systems  software,  or  customized  programs,  with 
reproduction  involving  a  simple  process  of  replicating  code.  Thus,  it  might 
appear  that  software  development  organizations  would  resemble  job-shop 
environments.  Reinforcing  this  notion  is  a  tendency  of  many  programmers, 
managers,  and  academics  to  view  software  development  as  more  an  art  or  craft 
than  an  engineering  or  manufacturing  activity  suitable  for  discipline  and  control 
(Brooks   1975;    Shooman    1983;    Hauptman    1986). 

A  problem  with  continuing  to  view  a  technology  as  a  mere  craft  is  that 
such  attitudes  may  impede  progress  in  rationalizing  the  development  process.  In 
software  development,  progress  in  improving  productivity  continues  to  be 
agonizingly  slow.  One  study  concluding  around  1980  estimated  that  increases 
in  programming  output  per  man-hour  had  risen  only  about  5%  annually  since  the 
1960s,  in  contrast  to  improvements  in  computer  processing  capacity  averaging 
about  40b  a  year  (Horowitz  and  Munson  1984).  Despite  better  computer 
languages,  management  methods,  design  techniques,  and  tools  such  as  program 
generators  that  automatically  produce  code  from  high-level  designs,  demand  for 
programmers  in  the  mid-1980s  outstripped  the  supply  of  programmers  by  about 
10%  in  Japan   and  more  than   20%  in   the   U.S.    (Zavala   1985;    Aiso  1985). 

Observers  began  referring  to  this  supply-demand  imbalance  as  the 
"software  crisis"  as  far  back  as  1969  (Hunke  1981;  Frank  1983).  In  fact,  U.S. 
companies  desiring  to  buy  fully  customized  applications  programs  typically  had  a 
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3-  to  4-year  wait  (U.S.  Department  of  Commerce  1984).  In  Japan,  the  typical 
backlog  was  26.4  months  (Kamijo  1986).  Further  hardware  development,  in  large 
and  small  machines,  continues  to  expand  the  demand  for  lengthy,  complicated 
programs,  even  for  personal  computers,  delaying  for  years  the  full  utilization  of 
microprocessors  such  as  the  Intel  80286  and  80386  (Businessweek  1987).  In 
addition,  a  serious  impediment  to  improvements  in  individual  productivity  are 
quality  problems;  data  from  IBM,  TRW,  and  GTE  indicate  that  fixing  bugs  in  a 
completed  program  during  operation  can  cost  100  times  that  of  detecting  errors 
in   the  design   stage    (Boehm   1976). 

In  short,  the  lack  of  programmers,  rising  demand  for  software,  increasing 
length  of  programs  needed  to  utilize  improved  hardware  capacity,  as  well  as 
quality  problems,  have  created  a  need  to  raise  efficiency  levels  for  software 
development.  For  a  firm  to  build  the  capability  to  produce  a  variety  of 
software  products  of  high  quality  and  at  lower  costs  than  other  companies,  or 
simply  to  maximize  its  manpower  and  invested  resources,  should  also  provide  a 
competitive  advantage   in   the  marketplace. 


STRATEGIC  OPTIONS   FOR  PRODUCT-PROCESS   DEVELOPMENT 

Determining  why  managers  make  the  choices  they  do,  or  whether 
organizations  evolve  from  deliberate  decisions,  is  a  complex  subject  of  frequent 
and  conflicting  debate  (Scott  1981).  But,  certainly,  in  designing  new  products 
and  processes,  there  are  options:  Managers  can  refuse  to  worry  about  parts 
and  procedures  standardization,  and  encourage  their  engineers  to  design  highly 
marketable  products,  which  then  might  be  mass-marketed.  These  firms  might 
even  be  insensitive  to  development  costs,  if  they  could  recoup  large  profits 
from  mass  sales,   although,    if  they  have  a  shortage  of  personnel,   they  may  still 
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want  to  maximize  individual  productivity.  On  the  other  hand,  companies  that 
choose  to  customize  products  might  have  even  greater  incentives  to  exploit 
similarities  in  tools,  procedures,  or  parts  across  different  product  lines.  Firms 
pursuing  standardization  (package)  or  customizing  strategies,  but  especially  the 
latter,  might  thus  want  to  standardize  the  development  process  and  major 
components,    to   reduce  costs   and  perhaps   improve  quality  as  well. 

This  can  be  illustrated  as  follows.  If  a  customer  needs  a  product,  whether 
it  is  an  automobile,  a  machine  tool,  a  semiconductor  chip,  or  a  software 
program,  there  are  basically  three  options:  obtain  a  fully  customized  product-- 
from  a  vendor  or  an  in-house  department;  obtain  a  standardized  or  "packaged" 
product;  obtain  a  semi-customized  product  (from  a  vendor  or  an  in-house 
department  that  modifies  a  purchased  standardized  product).  It  follows  that 
vendors  should  have  three  corresponding  options:  1)  sell  a  customized  product; 
2)  sell  a  standardized  product;  3)  customize  a  semi-standardized  product. 
Design  managers  can  adopt  one  of  several  strategies  to  manage  product  and 
process  development.  Except  for  a  Model-T  type  of  factory,  where  all  end 
products  and  processes  are  fully  standardized,  the  analogies  appear  to  apply 
both   to  software  and   hardware: 


'    A     similar    typology    has     recently    been    suggested    in     Lampel    and 
Mintzberg    1987. 
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Table  1:    STRATEGIES   FOR   PRODUCT-PROCESS  DEVELOPMENT 

FULL  CUSTOMIZATION:  IMPLEMENTATION: 

Customize  inputs   and   development  Maximize  the  capability  of  the 

process   for  each   product  organization   to  produce  a   unique 

product    that    will    capture    a    high    price 
from  at   least  one  customer 

Hardware  Analogy :  Job   Shops 

Software   Analogy :  Small    Laboratory    Environment 

SEMI -CUSTOMIZATION/BATCH:  IMPLEMENTATION: 

Customize   some   inputs   and   processes     Maximize  the  capability  of  the 
and   sell   more  than   one  organization   to  produce  a   unique 

of  each   product  product  that  will   capture  a   large 

share  of  the  market 

Hardware  Analogy :  Batch    Processing 
Software   Analogy :  Large  Development   Center 

FULL  STANDARDIZATION:  IMPLEMENTATION: 

Fully   standardize   inputs,    processes        Maximize  the  capability  of  the 
and  final   products  organization   to  produce  a   product 

with     standard    features    at    the    lowest 

possible  price 
Hardware  Analogy  :Model-T   Factory 
Software  Analogy :  Undesirable? 

SEMI-STANDARDIZATION/-CUSTOMIZATION:  IMPLEMENTATION: 

Standardize   inputs   and   processes  Maximize  the  capability  of  the 

but  customize  end   products,  organization   to  produce   semi-custom 

with   large-factory  efficiency  products   at  a   low  price  through 

the     use     of     as     many     standardized 
procedures   and   inputs   as   possible 

Hardware  Analogy :  Small-Lot   Production,    Group   Technology 
Software   Analogy :  Software   Factory 

STANDARDIZED  CUSTOMIZATION:  IMPLEMENTATION: 

Standardize   inputs   and   processes  Maximize  the  capability  of  the 

but  customize  end   products   and  organization   to  produce  customized 

automate  processing  products   at  a   low  price  through   the 

use  of  highly  flexible  process  techniques 

and/or  automation 

Hardware  Analogy :  Automated   Flexible  Manufacturing  Systems 

Software  Analogy :  Program  Generators,    Used    in    Factories   or   Independently 
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The  idea  of  creating  "software  factories"  to  develop  standardized 
procedures,  tools,  and  program  components  reusable  across  different  products 
appears  to  have  been  first  proposed  by  a  Honeywell  engineer  at  a  1968  NATO 
Science  Conference  on  improving  software  productivity.  Conference  members 
criticized  the  idea  as  unworkable,  largely  due  to  three  problems:  One,  it 
seemed  too  difficult  to  create  program  modules  that  would  be  efficient  and 
reliable  for  all  types  of  systems  and  which  did  not  constrain  the  user.  Two,  it 
seemed  impossible  to  write  software  that  did  not  depend  on  specific 
characteristics  of  particular  machines.  And  third,  no  method  was  then  available 
to  catalog  program  modules  so  they  could  be  easily  found  and  reused.  (Horowitz 
and  Munson   1984,    citing  Mcllroy   1976;    McNamara   1987). 

These  were  and  remain  serious  problems,  although  many  large  software 
producers  have  made  progress  in  facilitating  design  and  overall  development 
efficiency,  as  well  as  reusability  (Ramamoorthy  1984;  Horowitz  and  Munson  1984; 
Goldberg  1986).  Several  companies  and  even  the  University  of  Southern 
California  (Eliot  and  Scacchi  1986)  even  claim  to  have  established  software 
factories,  and  others  have  launched  less  elaborate  software  rationalization 
projects . 

Of  particular  importance  to  this  research  project  is  an  experiment  that 
occurred  at  System  Development  Corporation  (SDC),  a  producer  of  real-time 
software  primarily  for  government  contracts.  By  the  mid-1970s,  managers  had 
encountered  several  common  problems  they  hoped  a  more  factory-like 
environment  would  solve:  (1)  Lack  of  discipline  and  repeatability  or 
standardized  approaches  to  the  development  process,  with  the  result  that  SDC 
was  continually  reinventing  products  and  processes,  and  not  becoming  as 
proficient  at  development  or  project  control  as  managers  wanted.  (2)  Lack  of 
an  effective  way  to  visualize  and  control  the  production   process,    as  well  as  to 
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measure  before  the  project  was  completed  how  well  code  implemented  a  design. 
3)  Difficulty  in  accurately  specifying  performance  requirements  before  detailed 
design  and  coding,  and  recurrence  of  disagreements  on  the  meaning  of  certain 
requirements,  or  changes  demanded  by  the  customer.  4)  Lack  of  standardized 
design,  management,  and  verification  tools,  making  it  necessary  to  reinvent 
these  from  project  to  project.  5)  Little  capability  to  reuse  components,  despite 
the  fact  that  many  application  areas  used  similar  logic  and  managers  believed 
that  extensive  use  of  off-the-shelf  software  modules  would  significantly  shorten 
the  time  required  for  software  development.  Several  managers  and  development 
engineers  decide  to  integrate  a  set  of  tools  (program  library,  project  databases, 
on-line  interfaces  between  tools  and  databases,  and  automated  support  systems 
for  verification,  documentation,  etc.)  with  standardized  procedures  and 
management  policies  for  program  design  and  implementation,  and  utilize  this 
system  in  a  centralized  facility  of  about  200  programmers  in  Santa  Monica, 
California.  The  concept  and  system  of  tools  and  methods  SDC  copyrighted 
under  the   name   "The  Software   Factory"    (Bratman   and   Court   1975  and    1977). 

The  SDC  experiment  was  not  particularly  successful.  The  three  problems 
raised  at  the  NATO  conference  surfaced  at  SDC;  for  example,  it  was  extremely 
difficult  to  reuse  code  from  one  project  on  different  computers  and  for 
different  applications.  This  led  to  other  problems.  Most  seriously,  project 
managers  did  not  like  giving  up  control  of  development  efforts  to  a  centralized 
facility,  leading  to  a  decline  in  the  flow  of  work  into  the  factory. 
Programmers  also  tended  to  complain  about  unfamiliar,  rigid  standard,  as  well  as 
the  difficulty  and  inelegance  of  reusing  other  people's  code.  In  retrospect,  it 
seems  that  SDC  managers  attempted  to  impose  the  factory  infrastructure  of 
standardized  tools  and  methods,  and  reusability  goals,  on  both  project  managers 
and    programmers    before    software    technology    was    refined    enough    to    do    this 
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easily.  Furthermore,  architects  of  the  factory  failed  to  prepare  managers  and 
programmers  for  the  changes  and  to  adapt  the  work  flow  to  the  new  system. 
SDC  gradually  abandoned  the  effort  during  the  late  1970s,  although  it  continued 
to  use  many  of  the  factory  procedures  and  some  of  the  tools  (Cusumano  and 
Finnell   1987). 

Perhaps  the  most  significant  outcome  of  the  SDC  experiment  was  that 
reports  from  this  company  encouraged  several  Japanese  software  managers  to 
pursue  software  factory  organizations  or  at  least  greater  efforts  at  process 
control  and  reusability  (Iwamoto  and  Okada  1979;  Matsumoto  1981;  Mizuno  1985; 
Sakata  1985;  Shibata  1985  and  1986).  SDC  did  not  introduce  the  factory 
concept  into  Japan,  however.  Japanese  experimentation  with  centralized  and 
highly  disciplined  programming  environments  actually  predates  the  SDC 
experiment,  going  back  to  Hitachi's  opening  of  the  world's  first  facility  ca'led  a 
software  factory  in  1969.  NEC,  Toshiba,  and  Fujitsu  followed  in  1976-1977,  and 
NT&T   in   1985   (Table  2). 
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Table  2:      MAJOR  JAPANESE  SOFTWARE  FACTORIES 

Year        Company  Facility/ Project  Name  Software  Product  Area 

1969         Hitachi  Hitachi   Software  Works  Operating    systems    and 

Business   Applications 

1976  NEC  Software  Strategy   Project  Operating      Systems, 

Telecommunications, 
Business   Applications 

Numazu    Factory  Operating   Systems 

Fuchu   Software   Factory  Real-Time  Applications 

Kamata   Conversion    Factory         Business   Applications 

Omori   Software  Works  Business  Applications 

Software  Development   Division  Telecommunications 


Hitachi    1979;    Matsumoto    1981,    1984,    1987;    Shimoda    1986;    Fujino 
1984  and    1987;    Murakami    1987;    Yoshida    1987;    Toyosaki    1987. 


1976 

Fujitsu 

1977 

Toshiba 

1977 

Fujitsu 

1985 

Hitachi 

1985 

NT&T 

Source: 

Hit 
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Various  articles  and  reports  from  U.S.  sources  continue  to  find  a  more 
rationalized  approach  to  software  development  in  Japan  than  in  the  U.S., 
indicating  that,  in  software  as  in  other  industries,  Japanese  firms  may  be  again 
taking  the  lead  in  the  process  and  organizational  rationalizations  necessary  to 
improve  software  production.  Four  distinct  trends  seem  to  be  emerging  across 
different  Japanese  firms.  One,  is  this  construction  of  large,  factory-like 
facilities  to  integrate  tools,  methods,  and  processes  involved  in  software 
development.  Second  are  attempts  to  exploit  Japanese  traditions  of  teamwork, 
discipline,  and  individual  attention  to  quality  by  developing  software  tools  and 
planning  or  reporting  systems  that  facilitate  group  programming  and  a  teamwork 
methodology  throughout  the  software  life  cycle.  Third  are  quality  control 
techniques  designed  to  catch  bugs  early,  before  they  become  difficult  to  fix. 
And  fourth  are  national  as  well  as  company  efforts  to  improve  software  quality 
and  productivity  through  reusability  of  software  modules  and  automation  of 
software  production  (code  generation)  (Kim  1983;  U.S.  Department  of  Commerce 
1984;    Uttal    1984;    Businessweek   1984;    Johnson    1985;    Haavind   1986). 

For    example,    one    U.S.    group    touring    Japan    concluded    that,    while    the 

Japanese  were   not   developing   particularly   unique  or  advanced   software  tools, 

they  were  using  them  more  systematically  then  U.S.   firms   (Zelkowitz   1984).     A 

1984  U.S.   Department  of  Commerce  report  suggested  that  U.S.  firms  have  lagged 

in  production  management  because  they  tend  to  view  software  more  as  a  "craft" 

than  the  Japanese: 

The  Japanese  have.  .  .made  impressive  gains  in  the  development  of  software 
tools  and  have  encouraged  their  widespread  use  within  their  software 
factories  to  boost  productivity ...  By  contrast,  while  the  United  States  is 
developing  software  engineering  technology,  the  use  of  tools  in  U.S.  firms 
is  quite  limited...  Many  U.S.  software  companies  consider  programming  a 
craft  and  believe  the  future  strength  of  the  industry  lies  in  its  creativity 
rather  than  a  disciplined  approach  to  software  development  as  do  the 
Japanese. " 
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A   1985  headline  in  the  Electronic  Engineering  Times  claimed  the  Japanese  were 

more    effectively    utilizing    team    or    group    approaches,     as    well    as    developing 

unique    team-oriented    software    tools,     while    Americans    were    becoming    overly 

dependent  on    small   groups   and   highly   skilled   individuals: 

"[T]he  approach  to  software  technology  taken  by  major  developers  in 
Japan,  such  as  NEC,  Fujitsu  Ltd,  and  Hitachi  Ltd.,  universally  strive  to 
harness  that  tradition  of  excellent  teamwork...  Each  of  these  developers 
has  automated  versions  of  planning  and  reporting  systems  that  enforce  a 
strict  teamwork  methodology  through  the  complete  life  cycle  of  a  computer 
program  --  from  planning  to  design  to  maintenance,  and  without  coding, 
since  high-level  language-source  codes  are  automatically  produced  from  the 
design  documents.  .  .  .  Until  now,  the  Japanese  have  been  hampered  in  their 
software  development  efforts  by  a  lack  of  team-oriented  tools.  The  tools 
borrowed  from  the  United  States  simply  do  not  fit  the  Japanese  culture 
because  they   put  too  much   control    in   too  few   hands. 

In  America,  industrial  software  development  is  generally  done  in  groups 
that  are  as  small  as  possible  to  minimize  the  communication  problems 
among  people.  That  makes  the  knowledge  of  each  individual  programmer  a 
critical  factor  to  the  success  of  any  software-development  project. 
But.  .  .that  is  just  not  tolerable  in  the  Japanese  culture.  As  a  consequence, 
the  Japanese  have  had  to  perform  basic  research  into  software  tools  that 
can  be  wielded  by  many  hands  at  once.  Nobody  else  was  going  to  develop 
group-programming  tools   for  them." 


If  national  differences  are  emerging  in  the  management  of  a  particular 
technology,  there  must  still  be  reasons  other  than  simply  location.  One 
explanation  might  be  historical,  such  as  a  less  prominent  software  craft  culture 
("hackers")  in  Japan,  as  opposed  to  the  U.S.,  or  simply  more  emphasis  of 
Japanese  companies  on  disciplined  engineering  and  manufacturing  practices.  But 
one  clear  difference  between  Japan  and  the  U.S.  is  the  composition  of  their 
software  markets,  which  should  affect  managerial  strategies  and  firm  structures. 
In  the  U.S.,  about  60%  of  software  sales  in  the  early  1980s  were  standardized 
packages.  In  contrast,  only  about  5%  of  Japanese  software  sales  were 
standardized  packages;  95%  involved  some  degree  of  customization  (Table  3). 
One  reason  for  this  difference  is  that  microcomputers  accounted  for  only  about 
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10%  of  Japanese  software  sales,  compared  to  about  50%  in  the  U.S.  But 
Japanese  customers  also  preferred  to  buy  customized  systems,  placing 
tremendous   demands   on   Japanese   software   producers. 

Table  3:    SOFTWARE  MARKETS  COMPARISON   (1984-85) 

Japan  USA 

Overall  Market  Characteristics: 

Total  Market    Revenues    (Billion   $) 

Annual   Demand    Increases    (%) 

Annual   Growth    in   Supply  of   Programmers    (%) 

Typical  Wait  for  Customized   Programs    (Months)    26 

Product/Market  Breakdown: 

Integrated    Systems    Software    (%) 
Package  Software    (%) 
Custom  Software   (%) 

Microcomputer  Software/Total   Market   (%) 
All   Systems   Software 
All   Applications   Software 

Computer  Manufacturers  as   Suppliers  of: 

Ai!    Systems    Software    (%) 
All   Applications   Software   (%) 

Sources:  U.S.   Department  of  Commerce  1984;  Zavala  1985;  Aiso  1986;   Kamijo 

1986;    Businessweek  1987. 

Note:  The   figures    cited    are   estimates    by   the   author   from   data    in    the 

listed  sources.  Systems  software  includes  operating  systems, 
database  management  systems,  telecommunications  systems,  and 
related  programs.  The  size  of  the  Japanese  software  market  is 
underestimated  because  systems  software  is  usually  sold  bundled 
with    hardware. 
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25 

25 

13 
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U.S.  companies,  as  well  as  the  Japanese,  have  continued  to  develop  better 
software  tools,  methods,  and  programming  environments  (Stucki  and  Walker 
1981;  Willis  1981;  Boehm  1984;  Howes  1984;  Griffin  1984;  Hoffnagie  and  Beregi 
1986).  This  is  the  case  even  though  SDC  and  other  American  firms  no  longer 
use  terms  such  as  "factories"  and  appear  to  prefer  designations  such  as 
"laboratory"  or  "systems  development  center,"  or  no  label  at  all,  to  refer  to 
their  software  organizations  (McCue  1978;  Hunke  1981).  But  another  question  is 
to  identify  which  software  facilities  have  truly  pursued  a  level  of  integration 
and  standardization  among  people,  systems,  functions,  tools,  methods,  and  inputs 
sufficient  to  distinguish  their  operations  from  other  large  facilities  with  minimal 
standardization   and   integration. 


THE  SURVEY 

The  published  descriptions  and  stated  objectives  for  the  SDC  Software 
Factory  project  (Bratman  and  Court  1975  and  1977)  provided  a  basis  for 
thinking  about  criteria  to  compare  software  facilities  along  a  spectrum 
commonly  thought  to  exist  at  least  for  large-scale  engineering  and 
manufacturing  operations:  process  standardization  and  control;  and  inputs 
standardization  and  control  (emphasis  on  reuse  of  software  modules).  The  basic 
factory  infrastructure  SDC  espoused  consisted  of  a  centralized  program  library 
to  store  modules,  documentation,  and  completed  programs;  a  central  database  to 
track  production-management  data;  standardized  project  databases  for  groups 
working  on  different  parts  of  a  program;  an  interface  linking  various  tools  and 
databases;  and  a  uniform  set  of  procedures  for  specification,  design,  coding, 
testing,  and  documentation.  It  was  decided  that  these  variables  should 
constitute  the  core  of  the   survey,    to  see   if  current  managers    in   the  U.S.    and 
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Japan  were  also  emphasizing  a  similar  type  of  infrastructure.  In  addition,  since 
an  objective  of  the  factory  strategy  was  to  produce  standardized  components 
for   reuse,    several  questions  were  composed  about   reusability. 

Major  software  producers  in  Japan  and  the  U.S.  were  identified  through 
literature  surveys  and  lists  of  software  producers,  and  sent  a  questionnaire 
containing  eight  core  questions  plus  more  than  a  dozen  others,  many  of  an 
experimental  nature,  to  provide  supplementary  data.  Optional  questions  also 
requested  performance  measures  such  as  actual  rates  of  reused  code  in  a  recent 
sample  year.  For  the  core  questions,  managers  responsible  for  production 
management  were  asked  to  rank  the  emphasis  of  themselves  and  other  managers 
at  their  facilities  on  a  scale  of  0  to  4  (see  Table  4),  as  well  as  to  comment  on 
each  answer.  Questionnaires  were  directed  to  managers  at  the  facility  or 
product  area  level,  since  software  practices  often  differed  enormously  among 
divisions  in  diversified  or  large  firms,  and  some  diversity  seemed  useful  to  meet 
different  market  or  internal  needs.  The  sample  was  limited  to  facilities  or 
departments  making  products  that  usually  require  large  amounts  of  people,  time, 
and  tools  to  develop,  and  which  might  therefore  provide  incentives  for  managers 
at  least  on  the  facility  level  to  seek  similarities  and  common  components  or 
tools  across  different  projects:  operating  systems  for  mainframes  or 
minicomputers  ("systems"  software) ;  and  real-time  applications  programs,  such  as 
for  factory  control  or  reservations  systems  ("applications"  software).  These 
were  further  broken  down  into  telecommunications  software  (applications  and 
systems  were  combined  because  of  the  smallness  of  the  sub-sample);  commercial 
operating  systems;  industrial  operating  systems;  real-time  control  applications; 
and  general   business   applications. 

All  the  Japanese  firms  contacted  filled  out  the  survey;  about  75%  of  U.S. 
firms  contacted  completed  the  survey.     To  check  answers,  two  managers  at  each 
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firm  or  facility  either  responsible  for  overall  software  engineering  management 
or  with  sufficient  experience  to  present  an  overview  of  practices  for  the  entire 
facility  were  asked  to  respond.  About  half  the  companies  returned  two 
completed  surveys  for  each  type  of  facility;  the  answers  were  extremely  similar, 
usually  differing  by  only  a  few  percentage  points,  and  were  averaged.  Other 
answers    represent  single   responses."^ 

Comments  from  the  respondees,  site  visits  and  interviews,  as  well  as 
partial  correlation  analysis,  revealed  that  many  of  the  non-core  questions  were 
not  particularly  useful  for  measuring  "rationalization"  along  large-scale 
engineering  and  manufacturing  lines.  For  example,  three  questions  asked  for 
emphasis  on  standardization  of  languages  for  high-level  design,  module 
description,  and  coding.  It  turned  out  that  Japanese  and  English  were  mainly 
used  for  high-level  design,  and  many  managers  did  not  know  how  to  answer; 
Japanese  tended  to  develop  specialized  languages  for  module  description  because 
they  were  less  comfortable  than  U.S.  programmers  in  using  English-based 
languages  for  this  purpose,  which  made  it  unfair  to  U.S.  firms  to  use  this 
question;  and  coding  languages  were  often  determined  by  customers.  A  question 
about  top-down  design  was  discarded  because  emphasis  on  this  tended  to 
contrast  with  a  more  factory-type  process  of  combining  new  and  old  code  in 
layers.  Similarly,  questions  about  emphasis  on  high-level  abstraction  or  layering 
were  discarded   because   not  everyone   knew   how  to   interpret  these. 

A  factor  analysis  procedure  with  varimax  rotation  confirmed  that  the  eight 
process  and  reuse  questions  constituted  two  orthogonal  factors,  with  eigenvalues 


^  In  the  case  of  Toshiba,  a  single  large  facility  (approximately  2500 
programmers)  had  different  departments  producing  both  systems  and 
applications  programs  using  identical  procedures  and  tools,  and  the  manager 
responsible  for  technical  development,  Dr.  Yoshihiro  Matsumoto,  submitted 
one  set  of  answers  and  asked  that  they  be  counted  twice,  under  both 
systems   and   applications   facilities. 
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of  3.46  and  0.93;  these  explained  88.6%  of  the  variance  in  the  answers.  For 
each  factor,  the  variables  with  a  strong  loading  (approximately  0.5  to  0.8)  were 
summed  and  used  to  test  differences  in  the  average  Japanese  and  U.S.  scores,  as 
well  as  to  test  if  product  type  or  country  origin  of  the  facility  were 
significantly  correlated  with  the  process  and  reuse  scores."^  The  data  reported 
in  Tables  5  and  6  reflect  scores  for  each  dimension  on  a  basis  of  100%,  with 
maximum  scores  of  4  for  each  variable.  Table  7  compares  the  average  Japanese 
and  U.S.  responses  to  the  process  and  reuse  dimensions.  Table  8  summarizes 
the  results  of  one-way  analysis  of  variance  tests  to  determine  the  effects  of 
product  types  or  country  of  origin  on  the  scores  reported  for  the  process  and 
reuse  dimensions.  Tables  9  through  11  compare  actual  reuse  rates  reported  by 
the  Japanese  and  U.S.  facilities,  and  analyze  correlations  with  emphasis  on 
reusability,  types  of  products,  and  country  of  origin  of  the  reporting  facilities. 
It  should  be  noted  that,  while  the  Japanese  sample  size  seems  small,  the 
surveyed  firms  account  for  the  vast  majority  of  software  written  and  sold  in 
Japan.  The  top  three  Japanese  firms  ranked  by  software  sales  in  1986  were 
NEC  ($507  million),  Fujitsu  ($389  million),  and  Hitachi  ($331  million).  NEC 
ranked  fourth  in  the  world,  behind  IBM  ($5,514  million),  Unisys  ($861),  and  DEC 
($560).  The  Japanese  sales  figures  considerably  understate  actual  software 
development,  because  Japanese  firms  included  ("bundled")  systems  software  with 
mainframe  and  minicomputer  hardware  prices.  The  size  of  systems  software 
operations  corresponds  roughly  to  hardware  sales,  however.  The  largest 
Japanese  producers  of  mainframes  by  1986  sales  were  Fujitsu  ($2,470  million), 
NEC    ($2,275),    Hitachi    ($1,371),    and   Mitsubishi    ($185);    the   largest   sellers   of 


^  This  procedure  is  recommended  as  a  simple  data  reduction  technique 
by  Comrey  1973  and  Tabachnick  and  Fidell  1983.  Comrey  suggested  that 
loadings  of  .55  (explaining  30%  of  the  variance)  were  "very  good,"  and  .63 
(40%  variance)   or  over  "excellent." 

22 


minicomputers  were  Toshiba  ($766),  Fujitsu  ($620),  and  Mitsubishi  ($475) 
(Datamation  1987).  Other  large  Japanese  producers  of  software  included  in  this 
survey  were  subsidiaries  of  Hitachi  and  NEC,  including  Nippon  Business 
Consultants  and  Hitachi  Software  Engineering  (Hitachi),  as  well  as  NEC 
Software,  NEC  Information  Systems,  and  Nippon  Electronics  Development  (NEC) 
(Kiriu  1986).  Since  the  sample  is  relatively  small  in  absolute  numbers,  the 
results  of  this  analysis  must  be  considered  more  suggestive  of  patterns  existing 
at  software  facilities   in  the  U.S.    and  Japan,    rather  than   definitive. 
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Table  4:      SURVEY  AND  SAMPLE  OUTLINE 
SAMPLE:    n  =  38   (17  Japanese,   21    U.S.) 

SURVEY  PARTICIPANTS:      Software  Development  Managers 

ANSWERS   KEY: 


4  =  Capabil 

3   =  Capabil 

2  =  Capabil 

1    =  Capabil 

0  =  Capabil 


ty  or  policy  is   FULLY   USED  OR   ENFORCED 

ty  or  policy   is    FREQUENTLY   USED  OR   ENFORCED 

ty  or  policy   is   SOMETIMES    USED  OR   ENFORCED 

ty  or  policy   is   SELDOM   USED  OR   ENFORCED 

ty  or  policy   is   NOT    USED 


SURVEY  QUESTIONS: 

Process  Standardization  and  Control   (100%  =  Score  of  201 

1)  A  centralized  program  library  system  to  store  modules  and    documentation. 

2)  A  central  production  or  development  data  base  connecting  programming 
groups  working  on  a  single  product  family  to  track  information  on 
milestones,  task  completion,  resources,  and  system  components,  to  facilitate 
overall  project  control  and  to  serve  as  a  data  source  for  statistics  on 
programmer  productivity,    costs,    scheduling   accuracy,    etc. 

3)  Project  data  bases  standardized  for  all  groups  working  on  the  same 
product  components,  to  support  consistency  in  building  of  program 
modules,  configuration  management,  documentation,  maintenance,  and 
potential    reusability  of  code. 

4)  A  system  interface  providing  the  capability  to  link  support  tools,  project 
data   bases,    the  centralized   production   data   base  and   program   libraries. 

5)  A  uniform  set  of  specification,  design,  coding,  testing,  and  documentation 
procedures  used  among  project  groups  within  a  centralized  facility  or 
across  different  sites  working  on  the  same  product  family  to  facilitate 
standardization  of  practices  and/or  division  of  labor  for  programming  tasks 
and   related  activities. 


Components  Standardization  and  Control   (100%  =  Score  of  12) 

6)  Formal  management  promotion  (beyond  the  discretion  of  individual  project 
managers)  that  new  code  be  written  in  modular  form  with  the  intention 
that  modules  (in  addition  to  common  subroutines)  will  then  serve  as 
reusable   "units  of  production"   in  future  projects 

7)  Formal  management  promotion  (beyond  the  discretion  of  individual  project 
managers)  that,  if  a  module  designed  to  perform  a  specific  function  (in 
addition  to  common  subroutines)  is  in  the  program  library  system,  rather 
than   duplicating   such   a  module,    it  should   be   reused. 

8)  Monitoring  of   how  much  code   is   being   reused 

Additional:    Actual   percentage  of   reused  code   in   a    recent   sample  year 
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Table  5:      SUMMARY  AND  RANKING  OF  PROCESS  SCORES 

Note:    Japanese   Facilities   indicated   by  * 

COMPANY/FACILITY  32=100% 


Telecommunications  Software 

*NEC   Switching   Systems 

97.5 

*NT&T   Applications 

80.0 

AT&T   Bell    Labs   Applications) 

80.0 

*NT&T   Systems 

60.0 

Commercial  Operatina  Systems 

*NEC    Fuchu    Factory 

92.5 

*NEC   Software,    Ltd. 

90.0 

Control    Data 

87.5 

IBM-Endicott 

85.0 

IBM-Raleigh 

85.0 

♦Fujitsu    Numazu    Factory 

80.0 

♦Hitachi   Software  Works 

75.0 

Data   General 

67.5 

Sperry/Unisys 

60.0 

Industrial  Operatinq  Systems 

♦Toshiba   Software   Factory 

80.0 

Boeing 

75.0 

Real-Time  Control  Applications 

TRW 

100.0 

Sperry/Unisys 

100.0 

♦Toshiba   Software   Factory 

80.0 

Hughes   Aircraft 

85.0 

Boeing 

80.0 

SDC/Unisys 

70.0 

Honeywell 

50.0 

Draper   Laboratories 

32.5 

General  Applications 

♦NEC    Information   Services  95.0 

♦NECMita  92.5 

Control    Data  90.0 

♦Fujitsu    Kamata   Software   Factory  75.0 

♦Hitachi   Omori  Works  75.0 

♦Nippon    Systemware  70.0 

Martin   Marietta/Denver  70.0 

Martin   Marietta/MD  65.0 

Culiinet  65.0 

EDS/GM  62.5 

♦Nippon   Business  Consultants  55.0 

♦Hitachi    Software   Engineering  45.0 

♦Nippon    Electronics    Development  35.0 

Computervision  30.0 

DEC    (Educational    Software)  25.0 
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Table  6:      SUMMARY  AND  RANKING  OF  REUSE  EMPHASIS  SCORES 

Note:    Japanese   Facilities   indicated   by  * 

COMPANY/FACILITY  12=100% 
Telecommunications   Software 

*NEC   Switching   Systems  100.0 

*NT&T   Applications  91.7 

AT&T   Bell    Labs    (Applications)  58.3 

*NT&T   Systems  50.0 

Commercial  Operating   Systems 

*NEC    Fuchu    Factory  95.8 

*NEC  Software,    Ltd.  83.3 

IBM-Endicott  66.7 

♦Hitachi   Software  Works  66.7 

Control   Data  58.3 

♦Fujitsu    Numazu    Factory  58.3 

Sperry/Unisys  45.8 

Data  General  41 .  7 

IBM-Raleigh  16.7 

Industrial  Operating  Systems 

♦Toshiba   Software   Factory  100.0 

Boeing  25.0 

Real-Time  Control   Applications 

♦Toshiba   Software   Factory  100.0 

SDC/Unisys  91.7 

TRW  75.0 

Sperry/Unisys  66.7 

Hughes  Aircraft  45.8 

Boeing  25.0 

Honeywell  16.7 
Draper   Laboratories  8.3 

General  Applications 

♦Nippon    Systemware  91.7 

♦NEC  Mita  89.6 

♦Nippon   Business   Consultants  83.3 

♦Fujitsu   Kamata   Software   Factory  79.2 

Martin   Marietta/MD  79.2 

♦NEC    Information   Services  75.0 

Control    Data  75.0 

♦Hitachi   Omori  Works  66.7 

♦Hitachi   Software   Engineering  62.5 

EDS/GM  50.0 

♦Nippon   Electronics   Development  50.0 

Cullinet  48.6 

DEC   (Education  Software)  25.0 

Computervision  25.0 

Martin   Marietta/Denver  25.0 
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Table  7:      COMPARISON  OF  AVERAGE  JAPANESE  AND  U.S.    SURVEY  SCORES 


Dimension 

Process  (Std.    Dev.) 
Reuse   (Std.    Dev.) 


n  =   17 

n  =  21 

Japanese 

U.S. 

t-value 

75.1    (17.7) 

69.8   (21.3) 

0.84* 

79.0   (17.3) 

46.2   (23.9) 

4.75* 

p  <    .01 


Table  8:    EFFECTS  OF  COUNTRY  AND   PRODUCT  TYPE  ON   SURVEY  SCORES 

Test:      ONE  WAY   ANALYSIS   OF  VARIANCE 
n   =  38    (17  Japanese,    21    U.S.) 

A.       Effects   on    Process   Score: 

Variable  F-ratio        Siq.    Level 

Country*  .698  .4179 

Product  Typei*#         1.400  .2554 


B.       Effects  on   Reuse  Score: 

Variable  F-ratio        Siq.    Level 

Country*  22.586  .0000 

Product  Type««  .413  .7982 


U  Coded   as  0  =  Japanese  facility,    1    =   U.S.    facility 

#*        Coded    as     1     =    Telecommunications    Software,     2    =    Commercial    Operating 

Systems,     3     =     Industrial     Operating     Systems,     4    =     Real-Time    Control 

Applications,    5  =  General   Applications 
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Table  9:      COMPARISON  OF  AVERAGE  JAPANESE  AND  U.S.    REUSE   RATES 


n   =  9 

n   =    14 

Japanese   (Std. 

D.) 

U.S.    (Std.    D) 

t-value 

37.2%  (13.9) 

13.9   (14.4) 

3 . 836* 

*  p  <    .01 

Table  10:    REGRESSION  MODEL  OF   REUSE  RATES  AND   REUSE  SCORES 
n  =  23   (9  Japanese,    14   U.S.) 


F-ratio 

8.627 

Probability    Level 

.00787 

R-Squared 

.2912 

Table  11:    EFFECTS  OF  COUNTRY  AND  PRODUCT  TYPE  ON   REUSE   RATES 

Test:      ONE  WAY   ANALYSIS   OF  VARIANCE 
n  =  23   (9  Japanese,    14   U.S.) 

Variable  F-ratio       Sig.    Level 

Country*  14.718        .0010 

Product  Type#«  .790        .5470 


#  Coded  as   0  =  Japanese  facility,    1    =   U.S.    facility 

tttt       Coded   as    1    =  Telecommunications   Software,    2  =   Commercial   Operating 

Systems,    3  =    industrial   Operating   Systems,    4  =   Real-Time  Control 

Applications,    5  =  General   Applications 
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DISCUSSION 

The  survey  results  appear  to  support  two  hypotheses.  One  is  that 
variations  in  the  structures  of  organizations  (as  measures  by  the  process  and 
reusability  variables)  reflect  different  strategies  for  managing  product  and 
process  development.  Despite  potential  views  of  software  development  as 
largely  a  craft,  art,  or  "job-shop"  type  of  operation,  some  managers  at  facilities 
making  similar  types  of  products  clearly  placed  more  emphasis  on  control  and 
standardization  of  processes  and  inputs.  Scores  ranged  from  as  low  as  8.3%  to 
as  high  as  100%  (Tables  5  and  6).  It  may  be  difficult  to  distinguish  facilities 
ranking  within  a  few  percentage  points;  but  companies  on  opposite  ends  of  the 
spectrums  that  emerged  from  the  survey  rankings  --for  example,  Toshiba  versus 
Draper  Laboratories  in  real-time  applications  software  development  --  must  be 
different  and  in  instructive  ways.  Moreover,  the  analysis  of  variance  tests 
confirmed  that  product  types  as  defined  in  this  paper  had  no  significant  impact 
on  where  managers  scored  on  either  dimension  studied.  Process  and  components 
rationalizations  strategies  corresponding  to  what  Table  1  defined  as  "semi- 
customizationZ-standardization"  or  "standardized  customization"  occurred  across 
different  types  of  producers. 

A  second  hypothesis  supported  in  part  by  the  data  is  that,  as  indicated  in 
various  sources,  there  are  some  significant  national  differences  between  the  U.S. 
and  Japan  in  how  software  engineering  is  being  managed.  The  t-tests  indicated 
that  average  responses  on  the  process  variables  --  75.1%  for  the  Japanese  and 
69.8%  for  the  U.S.  --  were  not  statistically  different  (Table  7).  This  confirms 
that  tool  sets  were  basically  similar,  as  noted  by  the  Kim  survey.  It  also 
provides  evidence  against  the  notion  that  U.S.  managers  are  less  concerned  with 
process   control  and   standardization   than  Japanese  managers. 

On   the  other  hand,    the  Japanese  did   score  significantly   higher  on    reuse 
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emphasis  --  79.0%  compared  to  46.2%  for  the  U.S.  facilities.  Actual  reported 
reuse  rates  were  also  significantly  higher  in  Japan  (37%  compared  to  under 
14%),  as  well  as  significantly  correlated  with  managerial  emphasis  as  reflected  in 
the  reuse  variables  (Tables  9  and  10).  The  analysis  of  variance  tests  confirmed 
that,  while  country  of  origin  significantly  affected  the  reuse  score  and  actual 
reuse  rates,  product  type  was  not  significant  (Tables  8  and  11).  In  other 
words,  Japanese  applications  producers,  who  clearly  are  marketing  customized 
products,  as  well  as  Japanese  systems  producers,  who  supposedly  are  selling 
unique  basic  software,  both  tend  to  emphasize  reusability.  In  the  U.S.,  System 
Development  Corp. /Unisys,  and  to  a  lesser  extent  Martin  Marietta/Maryland  and 
TRW,  also  appeared  to  be  following  this  reusability  or  customizing  strategy. 
But,  as  suggested  earlier,  particular  features  of  the  market  in  Japan,  which 
almost  universally  has  demanded  customized  products,  perhaps  encouraged  firms 
to  pursue  standardization  and  customization  strategies  relying  on  the 
construction  of   reusable  components. 

Over  time,  if  not  at  the  present,  facilities  at  the  upper  end  of  the 
spectrum  may  become  able  to  produce  customized  (or  semi-customized)  products 
similar  in  performance  to  those  products  (packaged  or  customized)  made  by 
firms  at  the  lower  end  of  the  spectrum  but  at  a  lower  cost,  due  to  savings 
from  process  management  or  elimination  of  having  to  "reinvent"  components. 
This  should  provide  an  important  competitive  advantage,  as  it  has  in  other 
industries  such  as  semiconductors,  machine  tools,  and  even  automobiles.  If  some 
firms  deemphasize  discipline  and  cooperation  while  focusing  essentially  on  the 
individual  engineer,  the  individual  tool,  or  the  final  product,  then  they  may  not 
be  fully  developing  --  that  is,  compared  to  some  of  their  competitors-- 
orqanizational  capabilities  to  maximize  the  performance  of  their  technical  people 
and   invested   resources. 
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To  an  extent,  a  technological  and  managerial  change  in  focus  from  the 
individual  and  individual  tools  and  techniques,  to  the  organization  and  process 
management  --  reflects  a  movement  one  might  expect  with  any  product  and 
process  as  firms  accumulate  experience  in  design  and  production,  and  as  market 
demands  become  better  defined,  at  least  compared  to  the  earliest  days  of  an 
industry.  But  the  software  example  suggests  it  is  not  a  movement  necessarily 
constrained  by  the  nature  of  a  technology  or  product  types,  or  by  the  simple 
passage  of  time.  Case  studies  currently  in  progress  of  individual  firms, 
principally  SDC,  Hitachi,  Toshiba,  NEC,  and  Fujitsu,  will  examine  in  detail  the 
process  of  strategy  formulation  and  organizational  implementation  for  managing 
this   technology  more  effectively. 
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APPENDIX  TABLES 


VARIMAX  ROTATED  FACTOR  MATRIX 


Variable/Factor  Process 

library  0.72695 

central   database  0.60496 

project  database  0.68368 

interface  0.63757 

uniformity  0.46309 

design  for   reuse  0.33476 

reuse  promotion  0.03058 
monitoring  of   reuse         0.37010 


Reuse 

-0.00545 
0.40151 
0.26326 
0.35033 
0.13917 
0.78735 
0.81375 
0.71125 


EIGENVALUES  AND  PERCENT  OF  VARIANCE 


Variable 

Factor 

Eiqenyalue 

%  Va 

riance 

Cum.    Percent 

library 

1 

3.45564 

69.7 

69.7 

central   database 

2 

.93777 

18.9 

88.6 

project  database 

3 

.37063 

7.5 

96.1 

interface 

4 

.19213 

3.9 

100.0 

uniformity 

5 

-.07122 

.0 

100.0 

design   for   reuse 

6 

-.07956 

.0 

100.0 

reuse  promotion 

7 

-.15555 

.0 

100.0 

monitoring   reuse 

8 

-.25679 

.0 

100.0 
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